fix: sync declarative schedules on deployment rollback#3468
Merged
Conversation
When rolling back a deployment via ChangeCurrentDeploymentService, declarative schedules were not being synced to match the rolled-back deployment's worker metadata. This caused schedules to remain as configured by the most recent deployment instead of reflecting the target deployment's schedule configuration. The fix adds a call to syncDeclarativeSchedules after the deployment promotion is updated, using the target deployment's worker metadata to restore the correct schedule state. Co-Authored-By: nick <55853254+nicktrn@users.noreply.github.com>
Contributor
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Co-Authored-By: nick <55853254+nicktrn@users.noreply.github.com>
Contributor
Author
End-to-End Test ResultsRan the webapp locally with seeded test data (two deployments with different schedule crons). All tests passed. Test Results (3/3 passed)
Before/After EvidenceInitial State (v2 = Current, cron =
|
| Deployments | Schedules |
|---|---|
After Rollback to v1 (v1 = Current, cron = 0 9 * * *)
| Deployments | Schedules |
|---|---|
After Promote back to v2 (v2 = Current, cron = 0 17 * * *)
| Deployments | Schedules |
|---|---|
DB Verification
-- Before rollback:
test_schedule|my-scheduled-task|0 17 * * *|UTC|test_schedule_instance|t
-- After rollback to v1:
test_schedule|my-scheduled-task|0 9 * * *|UTC|test_schedule_instance|t
-- After promote back to v2:
test_schedule|my-scheduled-task|0 17 * * *|UTC|test_schedule_instance|t
Collaborator
|
ready |
ericallam
approved these changes
May 1, 2026
nicktrn
pushed a commit
that referenced
this pull request
May 2, 2026
## Summary Delete 34 `.server-changes/*.md` files that should have been cleaned up automatically when v4.4.5 (#3406) was merged but were stranded by a workflow race. ## Why these are stale The `update-lockfile` job in `.github/workflows/changesets-pr.yml` is what cleans up consumed `.server-changes/*.md` files on the release branch. When v4.4.5 was merged on 2026-05-01, the post-merge workflow run on `main` failed at `pnpm install --frozen-lockfile` (stale lockfile in the merge commit), and `cancel-in-progress: true` cancelled the in-flight run from the previous push — so `update-lockfile` never reached the cleanup step. Result: the 34 files described changes that v4.4.5 already shipped, and they were re-appearing in the v4.4.6 release PR (#3501) under "Server changes" plus showing up as deletions in its diff. ## What this PR keeps - `fix-rollback-schedule-sync.md` — genuinely new for v4.4.6 (#3468), the only server change introduced after v4.4.5 - `README.md`, `.gitkeep` — directory infrastructure - `dev-cli-disconnect-md` — leaving alone (typo'd filename from March, no `.md` extension, not picked up by the cleanup glob anyway) ## After merge The next run of `changesets-pr.yml` will refresh #3501 with a "Server changes" section that only lists the v4.4.6 entry, and the only `.server-changes/` deletion in its diff will be `fix-rollback-schedule-sync.md`. ## Related - #3505 is the proper underlying fix — collapses the three-job graph into a single atomic commit by `changesets/action` so this race can't strand the cleanup again. This PR is just the one-time catch-up for the files that already got stranded.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
✅ Checklist
Testing
ChangeCurrentDeploymentService) and confirmed it was missing schedule syncChangeCurrentDeploymentService(UI rollback, UI promote, API promote, finalize deployment) are now coveredpnpm run typecheck --filter webapp— passes cleanlyChangelog
When rolling back (or manually promoting) a deployment, declarative schedules were not being synced to match the target deployment's worker metadata. Schedules remained as configured by the most recent deployment rather than reflecting the target version's schedule configuration.
This fix adds a call to
syncDeclarativeSchedulesinChangeCurrentDeploymentServiceafter the deployment promotion is updated. It parses the target deployment's storedBackgroundWorkerMetadatato restore the correct schedule state. This covers both rollback and promote paths (UI and API). Errors are handled gracefully so they don't block the deployment change itself.Screenshots
N/A — backend-only change.
💯
Link to Devin session: https://app.devin.ai/sessions/0debf012b58c4132be778f8ea88cd2b6